» 



PCT/JP2004/Q13855 



h ^ a # it jt 

JAPAN PATENT OFFICE 



This is to certify that the annexed is a true copy of the following application as filed 
with this Office. 



m m # n h 

Date of Application: 

ffl s # 

Application Number: 
[ST. 10/C] : 



2003^ 9^223 

#H 2003-330772 
[JP2003-330772] 



reC'D 1 3 NOV 200^1 



wipo 



PCT 



m m a 

Applicant(s): 



•I v 



litil a 



Commissioner, 
Japan Patent Office 



PRIORITY DOCUMENT 

SUBMITTED OR TRANSMITTED IN 
COMPLIANCE WITH 
RULE 17.1(a) OR (b) 



2004^1 1^ 40 



03 

m 

CO 



i 

m 

o 
o 

3 




tttMHfr miE# 2004 - 3099191 



#gg 2003-33. 0 772 



^-v : 



1/E 



[Mi*] 

[fcTft] 
[HP£#IWHS] 

[3&E*] 

[ft*] 
[ft*] 



DCT03034 _ , ^ 

sp^l5^ 9B22H 

F01B 23/12 
F01C 17/00 



G1K 7P4, 9^-^*3^^- 



*-?-*\ ^y^flL G1K 7P4, ^ys-;v^rr>e^- 

^v~;v • * * y 

^nt^mtRtmtR^m? 152-52 gfta^v 7 

HH3 >^ K 



[ft*] 

[I1S0**] 396023362 

[ft*3U±*#] * T - ^fl^^tt _ 
[JS^Xtt*IMKIS*IB] CATENA CORPORATION 

mm] 
[#i^mMA] 

[|KM*^] 599086238 

^ZMEl THE INSTITUTE OFCOMPUTER 

BASED SOFTWARE METHODOLOGY AN 
D TECHNOLOGY 



100110559 



[ft**] 

[#Sdr] 
[ft*Xt**ffc] 
[*K#^1 

[^ifc^-o^] 

[M^iiH^l 164782 
[tfltt&tt] 35.000R 

[^#*] ^sm^fpit^fsffl 



3£= 
0422-39-3200 
0422-31-9444 



tbSE# 2004-3099191 



mm 2003-330772 



^-y : i/E 



A 

software generating method comprising: 
A step for defining a software requirements by use of Lyee 
methodology; 

A step for arranging the requirements defined by use ot 

Algebra process; on* 
A step for inputting the arranged requirements into Pallets 

and Scenario Function of the Lyee methodology to get the source code; and 
A step for running the gotten source code until the original 

requirements are met. 
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Lyee Methodology: 
A Formalization using Process Algebra 

Abstract. Over the last years, various methodologies and techniques have been elab- 
orated and proposed to improve one or many aspects related to the software develop- 
ment life cycle. However, despite the great effort in this research field, the production 
of clearly understood and modifiable systems still an ambitious goal and far from 
reached. This is due, on one hand, to the complexity and the subtlety of software 
themselves and, on the other hand, to the limitations of the current methodologies. 
Recently, a new and very promising methodology, called Lyee, has been proposed 
Intended to deal efficiently with a wide range of software problems related to different 
field, Lyee allows the development of software by simply denning their requirements. 

Nevertheless, since both the semantics of Lyee generated software together with 
the process of automatic generation of software from requirements are described using 
informal language, difficulties and confusions may arise when trying to understand 
and study this methodology. 

The main purpose of this paper is to formalize, using a process algebra, the pro- 
cess of automatic generation of software together with the semantics of Lyee gener- 
ated software. Actually, process algebra naturally support many concept of the Lyee 
methodology and consequently formalize them simply and elegantly. It offers the Lyee 
methodology an abstract machine more suitable than the Von-Newman one. In fact, 
this new abstract machine consider a program as chemical solution when molecules 
(different vectors of the lyee methodology) interact together to reach a collective goal. 

keywords:^ Methodology, Process Algebra, Operational Semantics, Bisimulation. 



1 Introduction 



Producing easily and quickly software with hight qualities is the basic concern of the software 
development research field. Over the last years, various methodologies and techniques have 
been elaborated and proposed to improve one or many aspects relat ^ t °; h ^ so ^ H d ^ 
opment life cycle. However, despite the great effort in this research field, the proton of 
clearly understood and modifiable systems still an ambitious goal and for from reached. This 
is due on one hand, to the complexity and the subtlety of software themselves and, on the 
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other hand, to the limitations of the current methodologies. In fact, almost all of the proposed 
methodologies fail to produce clearly understood and modifiable systems and then use is still 
considered to be an activity accessible only to specialists with a large array of competencies, 
skills and knowledge. This, in turn, leads to highly paid personal, high maintenance costs, 
and extensive checks needing to be performed on the software. For these reasons, companies 
are likely to welcome any new methodology promising demonstrable improvement m the 
software development cycle. 

Recently, a new and very promising methodology, called Lyee [6, 7, 8, 9] (governemen- 
taL methodologY for softwarE providencE), has been proposed. Intended to deal efficiently 
with a wide range of software problems related to different fields, Lyee allows the develop- 
ment of software by simply defining its requirements. More precisely, a developer has only 
to provide words, calculation formulae, calculation conditions (preconditions) and layout of 
screens and printouts, and then leaves in the hands of the computer all subsequent trouble- 
some programming process (e.g., control logic aspects). Despite its recency, the results of die 
use of Lyee have shown tremendous potential. In feet, compared to conventional methodolo- 
gies development time, maintenance time and documentation volume can be considerably 
reduced by using Lyee (as much as 70 to 80%) [7]. In [4], we proposed some classical static 
analysis techniques in order to improve many aspects of this methodology, in particular Lyee 

requirements. ■ . 

Nevertheless, since both the semantics of Lyee generated software together with the pro- 
cess of automatic generation of software from requirements are described using informal 
language, difficulties and confusions may arise when trying to understand and study this 
methodology. In addition, the ideas behind this methodology are described using a sequential 
langage which is not appropriate to support them. In feet, a Lyee generated software is ba- 
sically made of small components (called vectors in Lyee terminology), where each one has 
an atomic goal, that collaborate together by interaction in order to produce the desired results 
(global goal). It is, however, commonly known that a process algebra which naturally supports 
concurrency and communication is the appropriate langage to specify concurrent components 
and therefore it will provides a formal and worthy foundation to support the Lyee method- 
ology concepts. Among other benefic consequences of using process algebra with the Lyee 
methodology, many components (complete vectors or parts of vectors) of the actual version 
of Lyee, which their presence was forced by the sequential langage used to describe it, wdl 
no longer be necessary since they are naturally supported by process algebra. Actually, syn- 
chronization vector, most of the routing vectors, command vector, etc., are no longer needed. 
Thus we obtain a formal description of Lyee that is simple and that produce programshorter 
and consuming less time and memory. Besides, this formal description will be an inevitable 
start point for many interesting analysis of diverse aspects of this methodology. For mstance, 
to optimize the Lyee generated software or the software generation processes, we need a for- 
mal proof that the optimized program is equivalent to its original version. Formal equivalence 
checking or more generally model checking can be elegantly achieved when usmg process 

^foffiis paper, we first define a formal process algebra, called Lyee-calculus, that easily 
and naturally supports the basic concepts of the Lyee methodology. In fact, this calculus 
can be seen as an abstract machine which is more suitable to support the Lyee methodology 
concepts than the Von Newman one. This machine considers a program as a set of molecules 
that interact togelher to produce a final result. Secondly, we show how this calculus can 
formalize and simplify both the lyee vectors together with the whole software generation 
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process. Actually, we have formalize the whole process of the automatic generation of Lyee 

SOft ?h^ e rSSnder of this paper is organized as follows. In Section 2, we define the syntax and 
the semantics of the Lyee-calculus. In Section 3, we give a short and technical introduction to 
the Lyee methodology and an overview of its formalization using the Lyee-cakulus. In Sec- 
tion 4 we propose a detailed and complete formalization of the Lyee methodology using our 
calculus In Section 5, we present one case study that concretely shows both how a program 
is automatically generated from simple requirement together with a step-by-step description 
of the execution of the generated program. Finally, Section 6 provides concluding remarks on 
this work, and discusses some future work 

2 Lyee-Calculus 

Process algebra is a formal description technique for complex computer systems, especially 
those involving communicating, concurrently executing components [1,3,5]. Process algebra 
is generally referred as calculus in the literature since it involves a variety of mathematical 
and logic concepts (concurrency theory, operational semantics, complexity theory, logic, etc.) 
that goes beyond me process algebra field. „ , - M 

In this section, we give the syntax and the semantics of a new calculus, called Lyee- 
calculus, that we have specially define to formalize the Lyee melhodology. 

2.1 Syntax 

Lyee-calculus programs are systems composed of independent and parallel processes that 
communicate using hand-shake technique on named channels. The channel can be restricted 
so that only some process can communicate on them. A process can send a value v through a 
channel ^ by doing the action [i\e] (v corresponds to the valuation of e). Similarly, a process 
can receive a value from a channel by doing the action [tie]. A processus can also performs 
a silent action r. This special action, intended to represent internal behavior of a system such 
as synchronization between processes, is also useful to capture indeterminism within process 

^Th^syntax of processes is presented in Table 1. The intuitive meaning of each syntactic 
construction is as follows: 

. Sequence: [K].P, where K is a set of actions, is a process that has to perform all the 
action in K and then behaves as the process P. The order in which the actions m K have 
to be executed is not important Notice that for the sake of simplicity we write , . . . , k»J 
instead of [{ki, . • • , « n }]- 

. Parallel composition: P \ Q behaves as processes P and Q running in parallel. Each 
one of them may interact with the other on channels known to both, or with the outside 
word (environment or the end-user) independently from the other. When two processes 
synchronise on the same channel, the whole process will perform an action r and behaves 
as the remaining process. For instance, let's take the following process: 

P = PI | P2 
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Table 1: Syntax of Process Algebra, 



P,Q 



(Processes) 

[K].P (Sequence) 

j p j q (Parallel composition) 

| P + Q (Choice) 

j Pt> Q (Guarded choice) 

j p/£, (Restriction) 

| A0t) P (DefiniUon) 

| nil ( nil process) 

K,KuK 2 (Set of actions) 

{ K } (Single action) 



L,Li,L 2 



i>3 
e 



K X \JK 2 (Set union) 

(Set of channels) 
0 (Empty set) 

{ t y (Single channel) 

Li U L 2 (Set union) 

(Action) 
%\e (Send) 
%'le (Receive) 
T (Silent action) 

(Channel) 

(Arithmetic expression) 



with PI and P2 defined as follows: 

PI d M [%\A).PV 
P2 = J [itx].P2' 

then, process P performs a silent action r, indicating a synchronization P™ cesse ^ 
PI and P2 which actually consist in the transmission of the value 4 from PI to F2, and 
behaves as the remain process PI' | P7f. Semantically, we will note this transition as 
follows: 

p 1+ pi' | P2' 

The relation A will be formally defined later within this section. 

• Choice: P + Q behaves as P or as Q. The choice is deterministically (made by the 
environment) if both P and Q do not begin with a silent action, otherwise the choice is 
not deterministically. 

. Guarded choice: P > Q is the process that behaves as P until process Q is activated. 
Whenever the latter is activated, the former is stopped and cleared from memory. 
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Celt 



Figure 1 : Cell formalized as a process. 

. Resection: P/L is the process that behaves as P except that it can communicate with the 
environment using channels given in L only. 

• Definition: A{1) =' P is a defining equation where A is a process identifier, X are 
variables (parameters), and P may recursively involve A. 

• nil process: nil is the process that cannot perform any action. 

2.2 Example 

In this section, we show how to model a cell of memory as a process that interacts with its 
environment through its communication channels. As shown by Fig. 1, we consider that the 
cell has two ports (channels) of communication, in and out. The basic task of this cell is to 
infinitely wait a value on channel in and to make it available on channel out. The same value 
may be outputted as mush as necessary until a new value is imputed 

We write the process cell C-(«). meaning that the memory cell x holds the value v, as 
follows: 

C{v) = f [in x ly).C x {y) + [oui^.C*^) 
By capturing a memory cell as a process, we can add intelligence to it For |*^e,we 
can write a cell that it does not allow the access to its content until it will be initialized. This 
smart cell can be defined as follows: 

Cell(x) ^ [*n-7y].C(iO 
Now, giving two processes defined as follows: 

PI [in x \b].nil 
P2 d = [out x ly].nil 
it is easy to write a program where these two processes communicate through a cell x: 

PI | Cell{x) | P2 

The Fig. 2 shows the interaction between all the involved processes. Here are the different 
steps of that program execution: 

PI | Cell(x) | P2 = [in*!5].mZ | [in x 7y).C x {y) \ [ou1f?y}.nU 

^ C*(5) | [outflyYnil 

= ( [in'ly] .C x (y ) + [ouf\S] .C x {5) ) \ [out x 7y] .nil 

^ C x (5) 
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r 1 
pi 

< > 


in 


C(5) 


out 


, ^ 

P2 

s > 


5 


5 



Figure 2: Example of interacting processes. 

2.3 Semantics 

Hereafter we give the formal semantics of the Lyee-calculus. This semantics is denned by 
the Action Elation A , where P A Q means that there is a reaction amongst the sub- 
processes of P such that the whole can execute the atomic action k and becomes £ The 
Leraction relation is inspired by the Chemical Abstract Machine of Berry and Boudol £]. 
In this model, a process is considered as a chemical solution of molecules waiting to interact. 
To formally introduce the relation A , we need to define the following notions: 

• ^ is a relation that simplify processes by eliminating the nil process as follows: 

p^Ua^p nil + P^P nil>P°t*P 

nil\P^P P + nil°t+P P>nU^P 

nil/L nil 

. We denote by \e\ the set of values containing the result of the evaluation of the expres- 
sion Tlfe is a variable, it evaluation will be its domain (int, real, etc.). For the sake of 
simplicity, we consider that all variables belong to the real set. 

• m is the name of the channel used by the action k, i.e: 

n - 0 

(lie) i = (»?e) t = 0} 

Now, we let the interaction reaction A be the least relation that satisfies the rules given 
by Table 2. 

3 Informal Formalization of Lyee Requirements 

This section presents an overview of how the Lyee methodology generates software from 
imple^er requirements. Besides, through this overview we progressive y ^ducehowo^ 
ca^ simply and efficiently formalize this methodology using the Lyee-calculus. The complete 
formalization of the process of software generation of the lyee methodology will be given m 
the next section. 

3.1 Lyee requirements 

Within the Lyee methodology, requirements are given in a declarative way as a set of state- 
^containing words together with their definitions, their calculation conditions and then- 
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p« Q 



[»!e].P - P 



[*?e].P 2» Pb/e] 



_ H €jeL_ 
(Br) [r].P - P 



,„ , [JTil-P A P' „ , 

iR " ) [K 1 UK 2 ].P±[K 2 )P' 



(J?+) P + Q A Q' 



, . P * EL fl g <?' (A) - 



P>Q - Q 



P>Q A P'>Q 
P A P' 



PoQ A Q' 



P 4 **. k. 6L 
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attributes (input/output, types, security attributes, etc.). Table 3 gives an example of Lyee 
requirements. 



Table 3: Lyee Requirements. 



■ ■ 












a 


b+c 


b*e>2 


OF 


int 


secret 


c 






IS 


float 


public j 


b 


2*c+5 


C>0 


OS 


float 


public 


e 






IS 


float 


public 















The requirements given in that table correspond intuitively, in a traditional programming 
language, to the code given in Table 4. 



Table 4: 





ifb*e>2 

then a:=b+c; output(a); 
endif 


Sr. 


input(c); 


Sb 


ifc>2 

then b:=2*c+5; output(b); 
endif 


Sr. 


input(e); 
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repeat until a fixed 
point is reached 



if(b*e)>2 

then a:=b+c; output(a); 
endif 
input(c); 
ifc>0 

then b:=2*c+5; output(b); 
endif 
input(e); 

' T 



Figure 3: Requirement Execution. 

Within the Lyee methodology, the user does not need to specify die 0 5 de ^ c ^°I 1 ^ 
in which these definitions will be executed. As shown in Table 4, despite the feet that the 
definition of word a uses word b, statement s b is listed after the statement s a . As explained 
in the sequel, from these requirements, and independent of the order of statements, Lyee* 
able to generate code mat computes all the denned words. This simple idea has, as shown 
in [6 7 8 9] multiple beneficial consequences on the different steps of software develop- 
ment In fact it allows us to begin developing software even with incomplete requirements. 
Moreover, the user does not need to deal with control logic as with more classical method- 
ologies. The control logic part of the software will be, within the Lyee ^modology, auto- 
matically generated reducing consequent programming errors and time. Flexibility is ako a 
major benefit of the Lyee methodology since the maintenance task can be reduced to a simple 
modification of requirements (add, remove and/or modify words' definitions). 

Consequently, Lyee systems can be viewed as collections of independent components 
(satement) that interact together in order to produce the desired result. The concepts of oar 
process algebra sticks very well with this view since the Lyee-calculus considers a program 
as a chemical solution of molecules (processes) that interact together to reach the final goal. 
So, at a first glance, one can view a Lyee requirement LR composed of as a set of statements 
{si, . . . , s„} as a concurrent processes of the Lyee-calculus, i.e: 

LR — si | ... | s n 



3.2 Pallets and Scenario Function 

From the requirements in Table 3, a program can be automatically generated that computes 
the values of a and b and outputs them. This program will simply repeat the execution of these 
instructions until a fixed point is reached, Le. any other iteration will not change the value of 

^tton^r^^^^ 

implemented within the semantic. In fact, the processes (molecules) interact together until a 
state of no possible evolution (fix point) is reached. 

Let's be more precise about the structure and the content of the program that will be auto- 
matically generated by Lyee from requirements. Within the Lyee methodology, the execution 
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Global fixed point 



*ucond 
then ar^h+c; 
endif 




W04 

Computation and output 



W03 

Conditions 



Figure 4: Lyee Pallets. 

In J? J? J 

I MW04 ► W02 -*-W03« > 

Lj lj lj 



Figure 5: Scenario Function. 



of a set of statements, such as the ones given in Table 3, is accomplished in a particular man- 
ner In fact, Lyee distributes the code associated with statements over three spaces, called 
Fa/Zets(M^2,Wb3andW M )mtheLyeetemmology,asshownmFig.4 

Pallet W 02 deals with the input words. Pallet W Q3 computes the calculation conditions 
of the words and saves the results in boolean variables. For instance, the condition "b*e>2 
used within the definition of the word "a" is calculated in W<» and the true/false result is 
saved in another variable "a_cond". Finally, pallet Wbi deals with the calculation of the words 
according to their definition given within the requirements. It also outputs the values of the 

^StoShirfrom pallet W<,4, a Lyee program tries to compute the values of all the defined 
words until a fixed point is reached. Once there is no evolution in W 0 4 concerning the com- 
putation of the word values, control is given, by routing vector R4C, to pallet W 02 . In its 
turn this second pallet tries repeatedly to input values of words until a fixed point is reached 
(no others inputs are available) and then, by routing vector R2C, transfer the control to pallet 
Wos Finally, and similar to pallet Wb*. P*"* ^os tries to compute the calculation conditions 
of the words according to the requirements until a fixed point is reached. As shown in Fig. 5, 
this whole process (Wo4 — W m — * W 03 ) will repeat until a situation of overall stability is 
reached and the three pallet linked together are called Scenario Function. 

Using a sequential langage to implement a Lyee requirement forces the author of the Lyee 
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Try to reach it 




concretize 
90a) 



Ye 



Set finish Rag 



Set restart flag 



Figure 6: Predicate Vector. 



methodology to explicitly specify the order in which the pallet will be executed, the order 
according to which vectors in the same pallet have to be executed and how to pass control 
from one vector to another. In other word, this sequential langage forces the mtroduction of 
some aspects (routing vectors RC2, RC3, RC4, etc., tense control functions **. *«» 
etc.) that do not belongs to fondamental ideas of the Lyee methodology, and that they have 
considerably complicated this methodology. 

However, using the Lyee-calculus, we do not need any more to specify the order according 
to which the pallets will be executed, the order according to which the vectors of each pallet 
will be executed, how and when to pass control from one pallet to another, etc. All this detad 
will be naturally managed by our abstract machine. Consequently, a Scenario Function could 
be formalized as follows: 

SF = Ww I W03 I W 02 

Notice that the order according to which Wqa, Wm and W 02 is no more important and the 
routing vectors that connect these pallets are also eliminated. 

Lyee has established a simple program with a fixed structure (called a Predicate Vector in 
the Lyee terminology) that makes the structure of generated code uniform and ^dependent 
of the requirement content. The global program will be simple calls of predicate vectors. The 
structure of a predicate vector is as shown in Fig. 6. 

The goal of a predicate vector changes from one pallet to another. For instance, in the 
pallet Wbd, &e first goal is to give a value to a word according to its definition For the 
example shown in Fig. 4, the predicate vectors associated with the calculation of the word 
"a" and the word "b" are as shown in Fig. 7. 

Once there is no evolution in the calculation of the words, the Lyee generated code toes 
to outout the words which will be the next goal. The predicate vector having the goal ot 
outputting values is called the output vector. In pallet W m , we find two predicate vectors 
having as goal the associating of values with input words. Finally, in pallet W m , the goal ot 
the predicate vectors is to compute preconditions specified within requirements as shown in 
Fig. 8. 
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Finally, the Lyee program associated with the requirements given in Table 3 is as shown 
m ^owfusing the Lyee-calculus, W<*> and W a can be specified as follows: 

Wo4 = 54 1 LA-a | IAJb \ OA 

W QZ = L3_a | LSJb 
W Q2 = LIjb. | L2.c | J2 
The formal definition of the different vectors (L2, L3, L4, S4, etc.) will be given in the 
next section. 

3.3 Process Route Diagrams 

The Scenario Function presented in the previous section can be a complete program for a 
S^e cT of -&en requirements, particular when all the input and output words belong 
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Table 5: Lyee Generated Prog 


ram. 


Pallet 


Program 


Comments 




CallS4 
Do 

CallL4_a 

CallL4-b 
while a fixed point is not reached 
Call04 
CallR4 


Initialize memory 

Calculate a 
Calculate b 

GotoWo2 




Do 

CaUL2-e 

Call L2_c 
while a fixed point is not reached 
Call 12 
CaUR2 


Input results 
Goto Woa 


Wbs 


Do 

CallL3-a 

CallL3-b 
while a fixed point is not reached 
CallR3 


Calculate a-cond 
Calculate b-cond 

Go to Wo4 1 



Back to Screen 1 BacktoScreen2 




GoloSOTin2 GotoSawnS 



Figure 9: Screen Interactions. 



to the same screen and there is no use of any database. However, if we need to input and 
output words that belong to databases or to different screens interconnected together, then 
the situation will be more complicated. For the sake of simplicity, we deal, m the sequel, 
only with the case when we have many screens. Suppose for instance that we have three 
interconnected screens, as shown in Fig. 9, allowing a user to navigate from one to^ another. 
Suppose in each one of them the user can input, compute and output some words. Therefore, 
in the specification, the user must specify how these screens are interconnected. . 

Furthermore, it is not convenient to define only one scenario function in which we com- 
pute all the words defined in all the screens. In fact, some screens may not be visited tor a 
given execution of the program and then the computation of the value of their words will be 
lost For that reason, Lyee associates with each screen its owner scenario function that will 
be executed only if this screen is visited. The scenario functions associated with screens are 
connected together showing the move from one of them to another. In the Lyee terminology, 
many scenario functions connected together make up a Process Route Diagram as shown in 

Fl8 Us°ing the Lyee-calculus, we can formalize a screen s k as a process *( Sfc ) that control 
the execution of the process SF(s k ). Actually, the process SF(s k ) will be executed until it 
corresponding screen is reactivates (receiving a signal on the channel i*» associated to the 
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nnn 



1_1 



Back to Screen1=True 



Fv»«Tfufl ^. End 



Goto Scree n2=Trua 



| nnn 

J -»oVV 04 -*-W02 -»W 03 



Back to Screen2=True 



Screen 2 



Goto Screen3=True 



l qqq, 



SoeenS 




Figure 10: Processes Route Diagram. 



screen 
follows: 



s k ) and then will be killed to create a fresh instance of SF (*). This is formalized as 

Notice that a concret example will be given later in this paper to show how the function 
$(sk) works. 

3.4 Lyee Program 

To summarize, according to the Lyee methodology, a Lyee program contains several proces- 
sus route diagrams (PRD). Each of them is a set of ^nn^scenano^ 
Each scenario function contains three interconnected pallets W 02 , Wos and W«. Finally, pal 
let contains atomic vectors (signification vectors and action vectors). 

Using the Lyee-calculus, a Lyee program V containing the screens s k , is tormai- 

ized as follows: 

V(s u ...,s k ) = *(si,...,a fc )/£(*i. •••>«*) 
where • • - , s*) is the set of input and output channels. This restricts . . . , s k ) to 
communicate with the environment only on channels in £(si, . . . , s k ). 
The function ^ is defined as follows: 

•(•i, . . . . - (Uc*--> [^]-»(-)) > 

This function activates the SF of a screen Sfc whenever a true value is received on die cor- 
responding channel i-\ which formalizes a button or a menu item that a user may use to 
Se the corresponding screen, and kill all the processes when it receives a true value on 
channel t 8 ° which formalizes the Exit button (or a corresponding menu item). 
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Consequently, a Lyee system can be viewed as a collection of independent concurrent 
processes that communicate with each other to compute the desired output words. In contest 
with conventional sequential view of Lyee methodology, there are no need for various action 
vectors and control functions, no need of working memory areas, etc. More details about 
, Sfc ) together with concret examples will be given in the sequel. 

The next section gives a more detailed and complete formalization of the Lyee methodol- 



ogy- 



4 Formalization of the Lyee Methodology 

Let Use(e) denotes the set of words used in the expression e. For instance, Use{a * b + 1) = 
{a, 6}. Also, let F(S) be the following function: 

:F(0) = 0 
F({x}UA) = {*f?x}U^(A) 

Now let's see how to automatically generate software from simple user requirement us- 
ing the Lyee-calculus. Suppose that the user requirement contains fc screens . ..,«*}. 
Suppose also that each screen contains a set of statements where each one of them has the 
following form: (w,e,c,InOuUtype) where w is a word, e its definition, c its condition 
InOub to specify if it is input, output both or neither input no output (the value * is used 
for input word, o for output, io for both input and output and empty filed for neither input 
nor output) and type is its type (the type B is reserved for bouton). To define the program 
• • , s k ) associated with this requirement, we need to formalize the following vectors 
(processes): 



Signification Vectors 



veuiui | 
L A (x, e) = 

\F{Use{e))). 

\fM- 
nil 


wait to receive the value true (1) on the channel i% (from L 3 ) 
wait to receive the value of all the Use of e from the memory 
evaluate e and put the result in the memory cell of x 
finish — ■ 


L 3 (x, c) = 

[HUse{c))]. 

[*f!c]. 

nil 


wait to receive the value of all the Use of c from the memory 
evaluate c and send the result on the channel %% (to L 4 ) 
finish 


KM- 
nil 


wait to receive the value x on the channel %% 
(from the input vector) 
save the value of x in the memory cell of x 
1 finish 
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Action Vectors 



Input Vector 



[djx). 

[%\x). 

nil 



Comments 



wait to receive a value on the input channel d a 
send the value of x on the channel %% (to L 2 ) 
finish - 



Output Vector 



Comments 



O a {x) 



\d x \x). 
nil 



wait to receive the value of x from the memory 
send the value of x on the output channel d x 
finish 



Memory (Structural Vector) I Comments 



S A {x) = \fi!v\.S%{y) 



Routing Vector 



R 3 (b,e,s) = 



[F(Use{e))}. 

[t'\e). 

nil 



wait to receive any value (initialization) and then behave 

if you receive 2 behaves as S 4 ^z; 
(change the content of the cell x) 
if you send y behaves as S% (y) 
(do not change the content of the cell x) 



Comments 



wait until the bouton b be pushed 

evaluate the condition of the bouton 

send the result to the screen s (i.e., activate s if e = 1) 

finish ====== 



Pallet: The three pallets W 02 , W os and W<* of a given screen s are formalized as follows: 

Wo2(s) = |(u, ) *,*,i,B)es ^(, w ) l(tu,*,*,i,B)€s ^( W ) 

Wb4(«) = Uw3)e- <S»(«>) l (lu , e ,*,*,B)e^4^,e)) k-^w^ <W) 
where B denotes any type except B (complementary of B) and * denotes anything. 

Scenario Function: The scenario function, SF(s), attached to the screen s is formalized 
as follows : 

SF(s) = Woi(s) | W m (s) | W m (s) 
Control Function: The control function attached to a screen s, is formalized as follows: 

$0) = sf(s) > [t a *n]Ms) 

The control function attached to a set of screens is formalized as follows: 
•(•i, ....«»)- (Utar-*! [«™-l»W) > l* S0? l]-^ 
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Exempt 



Exit 



Figure 11: Case Study - One Screen. 



We suppose that s 0 is the screen that we find when we exit the program (exit screen that 
does not belongs to the screens of the program itself). 

Lyee Program: Finally, the Lyee program V{a lt ...,*) associated with the requirement 
containing the screens s x , . . - , s k is as follows: 

•P(si, ■ • - , s k ) = • • • , 8 k )/C{a u • • • » *fc) 
where the set £(«x, ...,.*) contains all the input and output channels and it is defined as 
follows: 

£<•!....,•*)-( U W) u ^ 

(«;,*,* ,t/o,*)€flfc 

The meaning of i/o is that mis field has to contains the value », o or io. We suppose also 
that Sl is the first screen that appears when the user runs this program 

5 Case Study 

In this section, we give a concrete example and describe step by step how a Lyee program 
nTocress in order to compute words within our Lyee-calculus. 

P "S ex^mpte that we P present contains only one screen (another example with two screen 
is gWen in the appendix) As shown by the requirement given in Table 6 a user can mput 
a word a, waits for the value of b and then exit the screen by pushing the bouton B 0 . The 
Fig. 11 illustrates such a screen. 







a 






i 


real 


b 


2*a 


a>0 


o 


real 


Bo 


so 


iClick 




B 



Table 6: Lyee Requirements : Screen I. 



This screen s a is composed from three statements: 

si = {{a, , , i, real), (b, 2 * a, a > 0, o, reaZ), (B 0 , «o, <?Zicfc, B)} 
According to the definition of a generic Lyee program given in the previous section, the 



Lyee program 



associated to the requirement given by Table 6 is as follows: 
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SF( Sl ) = Wo4(«i) I W 03 (si) I Wob(«i) 



*(«i) = 5F(si) > [i Sl ?l].$(si) 
where W 02 (si), Wbs(ai) and Woa^i) are as shown hereafter: 





W»(si) = ^2 (a) | / 2 (a) 




L 2 (a) = ItSTaJ. 

niZ 


hip) = [dja\> 
[i§!a]. 

niZ 


1 Wm(s,) - Ls(b, a > 0) 1 #3(50, cZ « cfc - ^ 


L 3 (6,<x>0) = [*S?o]. 

[4!(o>0)l. 
niZ 


i? 3 (B 0 ,cZicfc,s 0 ) - [cZB 0 ?cZzcfc]. 

niZ 







U4(6,2*o)| 


0*(b) 


1 


54(a) 
S 4 (6) 


= l?t?a]. 
SJ(a) 

= [A?*]. 


1,4(6,2* a) = 


B71]. 

L? 4 !(2*a)]. 
niZ 


0 4 (6) 


= [#6]. 
[4!6]. 

niZ 



Suppose now, that the end-user (environment) of this program wants to perform the fol- 
lowing sequence of actions : runs the program (activates the screen gives *e value J to 
the wJrd a, waits for the value of the word 6 and then exits the program by pushing the bouton 
B 0 - This comportement can be captured by the following process £: 



Process 




Comments 


£ = 
£1 = 
£2 = 
£z = 


[db!x]£ 3 
[d.Balclick}.nil 


activate the program (screen si) 
give the value 7 to the word a 
get the value of the word 6 
clicke the bouton B 0 to exit 



Let's see now how the program interact wirn mis envuumucm iu — — 

In other words, we want to have a trace of the program progress when executed m parallel 
with the program £ that implements the end-used actions, i.e., we look for the behaviors of 
V(si) I £ ■ The steps of this trace is as shown hereafter : 
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( By definition of V and S ) 

(By definition of V ) 

( > [% a °n].nil)/C(s y ) | [t*Mlj .gi 

, ( Synchronization 

- End-user activates the program by running the screen sj ) 

($(si)>[t so ?li.mO/ £ (si) I £1 

{ By definition of $ and £j ) 

((SF(ai)>[** 1 ?l].*(ai))>[» #0 ?l]-n^)/A*i) I 

( By definition of -SF ) 
(((Wbi(«i) I WbC'i) I W o 3 (*i)) > [^71].*(«!)) > ^°?l].mZ)/£(5 1 ) | 

( By definition of W02 and consequently h > 

( ((Wbi(«i) I £2(0) I ay«1 -fek]-mQ I W OT («i)) >...)>••• )/ £ C s 0 1 l&izi-^ 

.!» ( Synchronization 

- Through h end-user gives the value 7 to the word a ) 
({{W 0i (s 1 )\L i {a)\{{z$7}.nU)\W 03 (s 1 ))>...)>..-)/C(sJ \ € 2 

— (By definition of L 2 ) 

( ((WWsi) I ([»^].[3g!o).mQ | (fe!7).mQ | W<«(*i)) >•••)>••• I £z 

-I» { Synchronization 

- The value of a is communicated to 1*2(0) ) 

( ( (Ww(*i) I (Wi7].«*0 1 WwC-i)) >...)>••• )/ £ ( Sl ) I * 2 

= (By definition of W 0 4 ) 

{{S 4 (a)\S 4 (b)\L 4 {b,2*a)\0 4 {b)\W7)^ I * 

= (By definition of 54(a) ) 

(((M-^W) I S4(&) 1 L4(6 ' 2 * o) 1 ° 4(6) 1 ( ^- niZ) 1 WoM) t> • • • 

-I* ( Synchronization 

- The value of a is stored in the memory ) 
( (SJ(7) I 5 4 (6) I L 4 (b,2 * o) I 0 4 (6) I Wo3(«i)) > - • - 
( By definition of (7) and W03 ) 

( ((l3S?«]-SS(«) + bV-7)-St(J)) I ••• I a > °) 1 i?3 ^ Bo ' cZicfc ' So))) > • ' • 
= (By definition of L$) 

( ((bs?*l.flS(*) + M!H- S 4(7)) 1 ... 1 ((MM-l*3 ! (° > °)W Z ) I — 

.!> (Synchronization . 

- 77ie vo/we 0/0 is communicated to £ 3 (&) to compute the b condition ) 

( (S}(7) I 5 4 (6) I L 4 (M * a) | 0 4 (6) | ([4»(7 > 0)].nil) | . • • 
= (By definition of L 4 and evaluation of (7 > 0) ) 

( (SS(7) I S 4 (b) I ([4?l].^?a]-b 4 !(2 * a)].niZ) | 0 4 (6) | (B^ntl) I ••• 
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(Synchronization 

- TVie 6 condition is evaluated and communicated to L 4 (t>) to activate the 
computation ofb ) 

( (52(7) I S 4 (*>) I (MH-WKa * a)].mZ) I o 4 (&) I ••• 

(By definition of S% (7) ) 
( ((bt?*]-^) + MUi^(7)) | S 4 {b) I ([^?ol.L74K2 * a)].niZ) | 0 4 (l>) I ••• 
.!» ( Synchronization 

- The value of a is communicated to L 4 ) 

( (S 4 (7) I 5 4 (6) | ([#.(2 * 7)].niZ) | 0 4 (6) | R 3 (B 0 , click, s 0 )) >■■■ 

( By definition of S 4 (b) and evaluation of (2*7)) 
( (5|(7) | (\fi?b).S b 4 {b)) | (b 4 !(14)] .mQ | 0 4 (6) | fi 3 (B 0 , cZicfc, s 0 )) > • - - 
-I» ( Synchronization 

- 7%e value ofb (14) is stored in the memory ) 
( (32(7) | S\{U) | 0 4 (f>) | R 3 (B 0 , click, s 0 )) >•■■ 

(By definition of 5^(14) and 0 4 (6) ) 
( (52(7) | (W?*].flSto + MM-^(14)) I (fr 4 ?*>]-[<W™0 I ^(^o, cZicfc,s 0 )) > • • - 
.!» ( Synchronization 

- T/ie 6 value is communicated to 0 4 ) 

((S 4 (7) I 5$(14) | ([d b U4] .nil) \ R 3 {B 0 , click, s 0 )) >...)/C(s 1 ) \ € 2 
= (By definition of £■% ) 

( (£«(7) | S$(14) | ( [d b !14] .mZ) | J? 3 (B 0 , click, s 0 )) >■■■ )/£(*i) I [jfeM- g s 
( Synchronization 

- 7%e b value, stored in 0 4 , is communicated to the environment ) 
( (S 4 (7) I 5$(14) | R 3 (B 0 , cZicfc, s 0 )) I> • • • )/£(si) I S» 

= (By definition of R 3 and £3 ) 

((5J(7) I S 4 (14) I (\d B Jclick] .[t ea n}-nU)) > ... )/£(*0 \ ^.dick^ni! 
-I» ( Synchronization 

-The end-user push button B Q to exit ) 
(OW) I 5^(14) I ([^Mlj.mZ)) l> > [i s °n] .nil)/C(s 1 ) 
I* ( Synchronization 

-The system ends its execution ) 

nil 

To summarize, here are the main steps of the program progress: 

1 End-user activates the program by running the screen «i . 
( (fr 5 *?l] .$(si)) > [i*m}.nil)/C{ Sl ) I fr s Ml] .£i 

2. Through 72(a), end-user gives the value 7 to the word a 

( ( I W I (WWW I WW*)) >•••)>••• I l^lli^ 

3. The value of a is communicated to L 2 (a). 

( ( (Wbi(*i) I ([tS7tt].ba»a]-ng) I (MIZl.mZ) | W«(«i)) >•••)>•-• )/M*0 ' * 2 
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Figure 12: Interaction between processes. 



4 The value of a is stored in the memory, i.e. in 54(a). 

' ( ((bS?a}-g?(a)) I S 4 (*>) I L 4 {b, 2 * a) 1 0 4 (6) | (J^M-^O I > • • • 

5 The value of a is communicated to L z (b) to compute the b condition. 

' ( ((UOT-SSC*) + M1Z1- S 4(7)) I ... | ((MM-^Ka > 0)].niZ) I . . . 

6 The b condition is evaluated and communicated to L 4 {b). 

' ( (SJ(7) I 5 4 (6) | ([z|?l].^?o].[34'.(2 * a)].mZ) | 0 4 (&) I 0M- nil ) ' • ' ' 

7 The value of a is communicated, from memory, to L 4 (b). 

' ( ((bS?*].«J(*) + IgiZW 7 )) I 5 4 (6) I (MM-L? 4 K2 * o)].ni£) I 0 4 (i) I ••■ 

g The value of b is stored in the memory, i.e. in 54(6). 
' ( (5J(7) | (fj4?6].gS(b)) I (L? 4 Ul4)] .mZ) | 0 4 (6) | R 3 (B 0 ,click, s 0 )) > • • • 

9 The 6 value is communicated to the output vector 04(6). 
' ( (5?(7) | + [*|!141-S 4 6 (14)) | ([* 4 ?6].[<WmQ I s o)) > • • 

10. The 6 value, stored in 0 4 , is communicated to the envfronment 

( (5 4 (7) I 5^(14) | {[d b \U] .nil) | MB 0 , click, s 0 )) > . . . )/£(«i) I j£*i*P 3 

11. The end-user push button S 0 to exit. 

( (5f (7) | 55(14) | (fdta7d«cfc]. [»»ll].ni0) > . - • )/£(«i) \ \d Ba \chck].ml 

The Fig. 12 illustrates each of these steps. 

Furthermore, each transition could be validated by a proof. For instance, the transition. 

{V{sr)\S) ^ {V 1 {s 1 )\€ l ) 
where: 

TMsO = (*(*i) > [« so ?l].n»0/A*i) 
is justified by the following proof: 
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r 1 6 M 



gfo) S&j > fi-?U.ntf « . 16 111 



6 Conclusion 

In this paper, we have first defined a formal process algebra, called Lyee-calculus, that eas- 
ily and naturally supports the basic concepts of the Lyee methodology. In fact, this calculus 
can be seen as an abstract machine which is more suitable to support the Lyee methodology 
concepts man the Von Newman one. This machine considers a program as a set of molecules 
that interact together to produce a final result. Secondly, we have shown how mis calculus 
can formalize and simplify both the lyee vectors together with the whole software generation 
process Actually, synchronization vector, most of the routing vectors, command vector, etc., 
are no longer needed. We have also formalized the whole process of the automatic generation 
of Lyee software generation. This formalization offers to this methodology a formal seman- 
tics that allows one to clearly understand the concepts behind this methodology. Besides, this 
formal description will be an inevitable start point for many interesting analysis on diverse 
aspects of this methodology. For instance, to optimize the Lyee generated software or the 
software generation processes, we need a formal proof that the optimized program is equiv- 
alent to its original version. Formal equivalence checking or more generally model checking 
can be elegantly achieved when using process algebra. 

As future work, we want to more investigate the semantics of Lyee methodology in order 
to make it more simple and to generate, from requirements, more reliable and optimized 
code For the optimization end, we intend to define a congruence relation between processes 
of Lyee-calculus and then using it to prove the correctness of all the eventual optimizations. 
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Figure 13: Case Study - Two Screen. 



Appendix 

Case Study - Two screen 

The idea behind this example is to show the interaction between many screen. 



Word 


Definition 


Condition 


10 




a 






IS 




b 


2*a 


a>0 






B 2 


S2 


| click 







Table 7: Lyee Requirements : Screen I. 



Word | Definition 


Condition 


io |... 


e | 1+b 


b>0 


OS | ... 


Bn 1 so 


click 


I- 



Table 8: Lyee Requirements : Screen II. 

According to the definition of a generic Lyee program given in the previous section, the 
Lyee program associated to the requirement given by Tables 7 and 8 is as follows: 

SF(si) = Wb*(*i) I VM*i) I W<b(«i) 

SF(s 2 ) = Wo4(*l) I Wo3(*l) 

Notice that there is no W02 for th3 screen s 2 since it does not contain input words other than 
boutons. 

$(s 2 ) = SF{s 2 ) > [i*?l].*(«2) 
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£(si, s 2 ) = {d a , d b , d e , d Brn d Bll } 
V{S!, s 2 ) = s 2 )/£(si, «2) 



where: 



Wm(«i) = 


L 2 {a) | / 2 (a) 




L 2 (a) = ltS?a). 
nil 


h(a) = 


[d a ?a]. 
niZ 



W m (si) = L 3 (M > 0) | R S (B 2 , click, s 2 ) 


L 3 (fc,a>0) = K?a]. 

[«|l(a > 0)]. 
niZ 


Jl 3 (B 2 ,cZicfc,s 2 ) = [d B2 ?cZicfc]. 

[t'Ml]. 
nil 


I Wm(s 2 ) = L 3 (e,Z> > 0) 1 R 3 (B Q , chck, so) 


L 3 (e,o>0) = [t%lb\. 

[2|!(6 > 0)]. 
niZ 


R 3 (B 0 , click, s 0 ) = [d B Jchck\. 

[i 80 \l]. 
nil 



W^M = S 4 (a) | S 4 (6) | L 4 (6,2 * a) 1 OAb) 


5 4 (a) = l? 4 ?a]. 

5J(y) 

5 4 (b) = t? 4 ?*>]- 
5 4 b (y) 


L 4 (6,2*a) = [igllj. 

[i2?a]. 

L? 4 !(2*a)]. 

niZ 


o 4 (6) = 

[d b \b]. 
nil 


Wut(s 2 ) = 6' 4 (e) | L 4 (e, 1 + b) | 0 4 ( 


e) 


5 4 (e) = 

5 4 c (y) 


L 4 (e,l+6) = 

[ij?6]. 

l?$Ki + *>)]• 

niZ 


0 4 (e) = [*I?e]. 

[d e !e]. 
niZ 



si = {(a,,,*,s)»(^ 2 * a > a > °> 
Suppose now, that the end-user (environment) of this program wants to perform the fol- 
lowing sequence of actions : runs the program (activates the screen s{), gives the value 7 to 
the word a, waits for the value of the word b, pushes the bouton B 2 to go to the screen s 2 , waits 
for the value e and then exits the program by pushing the bouton B 0 . This comportement can 
be captured by the following process S : 



End-user Action 


Comments 


S 1 = [d a \7]£ 2 

e 2 = [d b n}£ 3 

£ 3 = [t B nclick]£ A 

£4 = [d e ?e}£ 5 

£ 5 — \i Btl \click].nil 


activate the program 
give the value 7 to word a 
wait for the value of the word b 
pushes the botom B 2 to go screen 2 
wait for the value of the word e 
push the botom B 0 to exit 
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1. End-user activates the program by running the screen 
V{s u s 2 )\£ ^ V x (s ly s 2 )\S 1 

where: 

Vi{s lt s 2 ) = (*(si) | [t-71].*W t> It*?l].fitf)//:(ai.«2) 

2. The end-user gives the value 7 to the word a. 
Pi(si,S2)|£i ^ Wt(«ii«a)|6 

where: 

= ((((WW-i) I l«Si7].«a I ««) I w-W) > I l^W*)) 

>{t»?l].na)/£(ai,s») 

3 The value of a is stored in the memory: This will be done in two steps. First the value ofa 
is communicated to L»(a) and second L 2 (a) will commumcate this value to the memory. 

The first step is as follows: 
where: 

>[t*°?l].niO/^(siiS2) 
In the second, the value of a will be stored in the memory of W<*: 

where: 

- (««P) I *W I W * a) 1 o 4 (6) 1 hm*)) > P?i]-*(i> I 

t>[t j °?l].nil)/£(*i**a) 
4. The valu of a is communicated to L 3 (6) to compute the 6 condition: 

Va{si 9 s 2 ) I £2 ^ ^5(si,S2) I £2 

where: 

so) = («SJ(7) 1 54(6) I Ltfr, 2* a) I 04(6) 1 14K7 > 0)] J* I «a(Ba, 1, dick)) 
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5. The b condition is.evahiated and communicated to L 4 (b) to activate the computation of b: 

V b {s u s 2 )\£ 2 ^ V 6 {si,a 2 )\S2 



where: 



s 2 ) = (((S|(7) | S<{b) \\f 4 K2* a)).nU | 0 4 ( &) \ Rs(B 2 , cUck)) 
t>[t« l ?l].$(si) | [i a2 ?l).*(s 2 )) > [i*?l].mQ/£(«a.*a) 

6. The 6 value is computed and communicated to 5 4 (&), the memory area of b: 

Ve(SuS 2 )\S2 ^ ^7(51,52)1^2 

where: 

>[l«?l].*(*l) | [f»?l].*(52)) > [l S0 ?l].niZ)/£(5l,52) 

7. The b value is outputted, i.e., communicated to the environment (end-user): 

7M«i, s 2) | £2 ^ Ps{buS 2 ) I S 3 

where: 

V^s u s 2 ) = (((flX(7) 1 51(14) I i*3(B2,5 2)C Zicfc)) > [i*71].»(«i) I b S2 ?l]-^(52)) 
>[t«71].nti)/£(ai,«a) 

8. The end-user push B 2 to go to screen 2: 

P 8 (si,5 2 ) I £3 ^ P»(*li*2) I f 4 

where: 

T 9 ( Sl ,s 2 ) - (((flff(7) I Sj(14)) > [t si ?l].*(si) I *(52)) > [t an n].nil)/C( Sl ,s 2 ) 

9. Get the value of b from the memory to compute the condition of e : 

P 9 (ai,a a ) I 7^10(51,52) I £4 

where: 

5 2 ) = (((»(7) I 5S(14)) > U ai ?l].*(5i) I (W^04(s 2 ) I [*I(14 > 0)].ntZ | 
10C } MBoXJick))> [W?l].$(5i)) > K«?l].mZ)/£( Sl)52 ) 
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10. Compute the value of e: 

Pio(*i,*a) I ^3 Vu(s u s 2 ) | £ 4 

where: 

7>u0*i, •») = (COW) I flJCM)) > [t* 1 ?!]-*^) I (*W I MIV^ 1 ° 4(e) 

1 1 . Store the value of e in the memory: 

where: 

12. Output the value of e: 

Tn{s u s 2 ) I S3 -* ^i 2 (si,s 2 ) I S> 

where: 

13. The end-user pushes B 0 to exit the program: 

TWa, s,) I £5 (((»(7) I 55(14)) > [t*?l].*(«i) I (S|(15) I 

niZ 
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in 


\ 

Cell 

— -J 


cut 

» — ► — 


P ■ 





Figure 1: Cell formalized as a process. 



f ^ 

PI 


in 


/ ' > 


out 
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f 1 
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Figure 2: Example of interacting processes. 

Table 2: Semantics of Lvee-Calculus 



m v P A O' Q' ^ Q 
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repeat until a fixed 
point is reached 

i ' 

if(b*e)>2 | 
thena:=b+c; output(a); 

endif 
input(c); 
ifc>0 

thenb:=2*c+5; output(b); 
endif 

input(e); , 



Figure 3: Requirement Execution. 



/( if ajccmd 
then a^b-k:; 
endif 

>fb_cond 
then b:~2*c-i-5; 
endif 



Partiat fixed poi nt 



r ^> 
( output(a); 

A outpuKbK J 



Global fixed point 



r 



Partial fixed point 



input(e); 
input(c); 



Pa rtial fixed poin t 



r 



second ^{b*e>2> 
b_cond:=(c>0) 




W04 

Computation and output 



W03 

Conditions 



Figure 4: Lyee Pallets. 
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Figure 5: Scenario Function. 
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Set restart Has 



I 



Figure 6: Predicate Vector. 
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b_condJmp" 
(O0) 



b_cond:= 
b^corcLtmp 



LZJb 




-^as- 



Set finish flag 



Set restart flag 



Back to Scraenl 



Back to Scmn2 




Figure 9: Screen Interactions. 




Screen 3 



Figure 10: Processes Route Diagram. 
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Signification Vectors 



Vector Comments 


L 4 (x,e) = 

WW]- I 

We), 
nil 


wait to receive the value true (1) on the channel %% (from L 3 ) 
wait to receive the value of all the Use of e from the memory 
evaluate e and put the result in the memory cell of x 
finish 


Lz{x, c) = 

\r(Uae{e))). 

[tf'.c]. 

nil 


wait to receive the value of all the Useotc from the memory 
evaluate c and send the result on the channel i% (to L 4 ) 
finish 


L 2 {x) = 

[««*]■ 


wait to receive the value x on the channel «f 

(from the input vector) 

save the value of x in the memory cell of x 

finish 



Action Vectors 





Input Vector 


Comments 


h{x) 


[djx]. 
[qix]. 

nil 


wait to receive a value on the input channel d x 
send the value of x on the channel %% (to i 2 ) 
finish 


Output Vector 


Comments 


0 4 (x) 


[ti?x]. 
[d*lx]. 
nil 


wait to receive the value of x from the memory 
send the value of x on the output channel d x 
finish 


Memory (Structural Vector) 


Comments 


S A (x) 

«f(y) 


= K?y].5f(y) 


wait to receive any value (initialization) and then behave 
as S%{y) 

if you receive z behaves as S%{z) 
(change the content of the cell re) 
if you send y behaves as S%(y) 
(do not change the content of the cell x) 


Routing Vector 


Comments 


R 3 {b, e 


,s) = 

[d b 7clik}. 

[HUse{e))). 

pie]. 

nil 


wait until the bouton 6 be pushed 

evaluate the condition of the bouton 

send the result to the screen s (Le., activate s if e = 1) 

finish 
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Exeniplei 



aC 



Bo 



Exit 



Figure 11: Case Study - One Screen. 



Wmisi) = L 2 (a) 1 h(a) \ 


L 2 (a) = 


[jSH 
nil 


I 2 (a) = ld 0 ?o]- 
[tjla]. 



Wwfsi > - a > 0) | R 3 (B 0 , chcfc, s 0 ) 


L 3 (b,a>0) = K?a]. 

[i|l(a > 0)]. 
niZ 


jR3(S 0 ,cZicfc,5 0 ) = 


[d Bo 7chckl 
nil 



Wyf^ = SJa) I &(6) I L 4 (M * a) I Q 4 W 



**») 



L 4 (6,2*a) = |t£nj. 

l? 4 !(2 *<*)]. 



0 4 (6) = [* 4 ?6]- 
[*!&]. 



[ Process 


I 


Comments 1 


S = 
ft = 

e 2 = 

£ 3 = 


<i{,?:r] -^3 


activate the program (screen si) 
give the value 7 to the word a 
get the value of the word h 
clicke the bouton B 0 to exit 
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r \ 

12(a) 








<3) 


C \ 

L2(a) 


v. 


* ' 






> 





a L 
bC 



Figure 12: Interaction between processes. 



Exemple 2 i 



B 2 . 



Exemple22 



eC 



pBfl. 



Exit 



Figure 13: Case Study - Two Screen. 



1 Wo2(s 1 ) = L 2 {a) | I 2 {a) \ 


L 2 {a) = KYoJ. 


/2(a) = 

nil 
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> 0) | Rz{B 2 > click, s 2 ) 


1 


L 3 {b,a>0) 


= [tS?a]. 

[«|I(a > 0)]. 
nil 


R 3 {B 2 , click, s 2 ) - 


[d B2 ? click], 
nil 




W™(s^ = L*fe,6 > 0) | R Z (B 0 , click, s 0 ) 


i 


L 3 (e,b>0) 


= [t 4 ?6J. 

b|!(b>0)]. 


J? 3 (Bo,chcfc,s 0 ) - 


[d Bo ? click]. 

[i so !l]. 

nii 



Wna(si) = S 4 {a) I 54(b) I L 4 (b,2 * a) 1 O4W 



5 4 (a) 
5 4 (6) 



5?(y) 



L 4 (b, 2 * a) = 



b 4 !(2*a)]. 



0 4 (6) = 



[<* 6 !b]. 
nil 



1 &4\:y) 

W { 


^(s-,) = S i {e)\L 4 (e,l + b)\U4{ 


.1 


S 4 (e) = 

St(y) 


Z, 4 (e,l + &) = [till]. 

bSK* + *>))• 

niZ 


0 4 (e) = [*S?c]. 

[d e !e]. 
raZ 



End-user Action 



s = 




Sx = 


[d a !7].£ 2 


£2 = 


[d b ?6].£ 3 


f 3 = 




£4 = 




£ 5 = 


\i Ba \click].nil 



Comments 



activate the program 
give the value 7 to word a 
wait for the value of the word b 
pushes the botom B 2 to go screen 2 
wait for the value of the word e 
push the botom Bp to exit 
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Abstract. Over the last years, various methodologies and techniques have been elab- 
orated and proposed to improve one or many aspects related to me software develop- 
ment Ufe cycle' However, despite the great effort in this research field, the production 
of clearly understood and modifiable systems still an ambitious goal and far from 
reached This is due, on one hand, to the complexity and the subtlety of software 
memselves and, on the other hand, to the limitations of the current methodologies. 
Recently a new and very promising methodology, called Lyee, has been proposed 
Sended to Jeal efficiently with a wide range of software problems related to dafferent 
field, Lyee allows the development of software by simply definmg their «<P^^ 
Nevertheless, since both the semantics of Lyee generated software together with 
the orocess of automatic generation of software from requirements are described using 
mto^rianW, difficulties and confusions may arise when trying to understand 
and study this methodology. , .. _„ 

The main purpose of this paper is to formalize, using a process algebra, the pro- 
cess of automatic generation of software together with the semantics of Lyee ^ gener- 
ated software. Actually, process algebra naturally support many , ^ n ^° f ^J-yee 
methodology and consequently formalize them simply and e egantly. It offers the Lyee 
methodology an abstract machine more suitable than the Von-Newman one. hi ft*, 
mis new abLct machine consider a program as chemical solution when molecules 
different vectors of the lyee methodology) interact together to reach a collective goal. 
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